[Amazon FSx for NetApp ONTAP] ボリュームのバックアップとリストアの裏側の処理を確認してみた
どんなアーキテクチャーでバックアップをしているのか気になる
こんにちは、のんピ(@non____97)です。
皆さんは「Amazon FSx for NetApp ONTAP(以降FSx for ONTAP)がどんなアーキテクチャーでバックアップをしているのか」気になったことはありますか? 私はあります。
AWS公式ドキュメントには以下のような記載がありました。
バックアップの仕組み
Amazon FSx バックアップは、スナップショット (ある時点のボリュームの読み取り専用イメージ) を使用して、バックアップ間の増分を維持します。バックアップが行われるたびに、Amazon FSx はまずボリュームのスナップショットを作成します (スナップショットはボリュームに保存され、SSD ストレージ層の領域が消費されます)。次に、Amazon FSx は、このスナップショットを以前のバックアップスナップショット (存在する場合) と比較し、変更されたデータのみをバックアップにコピーします。以前のバックアップスナップショットが存在しない場合は、最新のバックアップスナップショットの内容全体がバックアップにコピーされます。最新のバックアップスナップショットが正常に作成されると、Amazon FSx は以前のバックアップスナップショットを削除します。プロセスが繰り返される場合、最新のバックアップに使用されたスナップショットは、次のバックアップが作成されるまで、ボリュームに残ります。
バックアップ時にスナップショットを取得していることが分かります。ただ、スナップショットを取得して、「どこに」「どうやって」コピーするのかといった詳細が読み取れません。
気になって年を越せないと思ったので、監査ログからバックアップ / リストア時にどんな処理が動いているのか確認してみます。
いきなりまとめ
- ボリュームのバックアップを取得する裏側ではSnapMirror Cloudが動いている
- バックアップをする際の処理は以下の通り
- バックアップ対象のボリュームとS3オブジェクトストアとのSnapMirror Cloud relationshipを作成 (初回バックアップのみ)
- SnapMirrorによってバックアップしたいボリュームのスナップショットが取得される
- 取得されたスナップショットをS3オブジェクトストアにSnapMirrorでレプリケーションする
- リストアする際の処理は以下の通り
- ボリュームタイプDPでボリュームが作成される
- 作成されたボリュームとS3オブジェクトストアとのSnapMirror Cloud relationshipを作成
- S3オブジェクトストアからSnapMirrorでリストアする
- ジャンクションパスへのマウントや階層化ポリシー、スナップショットポリシーを設定する
- ONTAP CLIからバックアップで使用するSnapMirror Cloud relationship及び、SnapMirrorの履歴を確認することはできない
- バックアップ中にそのボリュームのバックアップをさらにしようとするとエラーになる
- バックアップIDとスナップショットの名前は一致する
- バックアップを削除すると、そのバックアップによって取得されたスナップショットも削除される
- バックアップが複数ある場合、最新のバックアップは削除できない
- バックアップによって取得されたスナップショットは削除することはできない
- ボリュームを削除しようとすると、その前段でSnapMirror Cloud relationshipが削除される
検証環境
検証環境は以下の通りです。
FSx for ONTAPのSVM上のボリュームをバックアップ及び、バックアップからリストアした時の挙動を確認します。
検証で使用したFSx for ONTAPファイルシステムとSVMは以下の通りです。
# FSx for ONTAPファイルシステム $ aws fsx describe-file-systems { "FileSystems": [ { "OwnerId": "<AWSアカウントID>", "CreationTime": "2022-12-27T02:14:03.283000+00:00", "FileSystemId": "fs-07987ca18f2f0e911", "FileSystemType": "ONTAP", "Lifecycle": "AVAILABLE", "StorageCapacity": 1024, "StorageType": "SSD", "VpcId": "vpc-043c0858ea33e8ec2", "SubnetIds": [ "subnet-0ddc1cafa116ba0dd" ], "NetworkInterfaceIds": [ "eni-0fe5133a37c0a0cee", "eni-099937bd040f30b0a" ], "KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/73e96c0a-aeb6-4813-aae6-1882c899d445", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-07987ca18f2f0e911", "Tags": [ { "Key": "Name", "Value": "non-97-fsxn" } ], "OntapConfiguration": { "DeploymentType": "SINGLE_AZ_1", "Endpoints": { "Intercluster": { "DNSName": "intercluster.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.8.164", "10.0.8.24" ] }, "Management": { "DNSName": "management.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.8.124" ] } }, "DiskIopsConfiguration": { "Mode": "AUTOMATIC", "Iops": 3072 }, "PreferredSubnetId": "subnet-0ddc1cafa116ba0dd", "ThroughputCapacity": 128, "WeeklyMaintenanceStartTime": "6:09:00" } } ] } # SVM $ aws fsx describe-storage-virtual-machines { "StorageVirtualMachines": [ { "CreationTime": "2022-12-27T01:44:48.078000+00:00", "Endpoints": { "Iscsi": { "DNSName": "iscsi.svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.8.122", "10.0.8.147" ] }, "Management": { "DNSName": "svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.8.23" ] }, "Nfs": { "DNSName": "svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.8.23" ] } }, "FileSystemId": "fs-07987ca18f2f0e911", "Lifecycle": "CREATED", "Name": "SVM", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-07987ca18f2f0e911/svm-084bd75da1359a531", "StorageVirtualMachineId": "svm-084bd75da1359a531", "UUID": "77ddac30-858c-11ed-b3ae-09cbea4eda09" } ] }
また、SVMにはvol1
という10GBのセキュリティスタイルがUNIX
のボリュームをマウントしています。
ボリュームをバックアップ
テスト用ファイルの作成
ボリュームのバックアップから確認します。
事前準備として、NFSクライアントから適当なテストファイルを作成します。
# マウントポイントの作成 $ sudo mkdir /mnt/fsxn # /vol1 をマウント $ sudo mount -t nfs svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn # マウントできたことを確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com:/vol1 nfs4 9.5G 256K 9.5G 1% /mnt/fsxn # テスト用ファイルを作成 $ sudo dd if=/dev/urandom of=/mnt/fsxn/random_block_file bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.48146 s, 166 MB/s # テスト用ファイルが作成できたことを確認 $ ls -l /mnt/fsxn total 1052712 -rw-r--r-- 1 root root 1073741824 Dec 27 02:41 random_block_file
ボリュームのバックアップ
次にボリュームのバックアップを行います。
バックアップはマネジメントコンソールから行います。バックアップの名前はvol1_backup_1
としました。
バックアップ開始後、監査ログとスナップショットを確認します。
# 監査ログの確認 ::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 02:50:50 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- ------------- ---------------------- ----------------- --------------------------------------------------------------------------------------------------------------------------- ------- ------- "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/?return_records=true : {"destination":{"path":"amazon-fsx-ontap-backup-us-east-1-1c8d1d45-678b6ae0:/objstore/0c000000-017b-975a-0000-0000003ae7a2","uuid":"0c000000-017b-975a-0000-0000003ae7a2"},"policy":{"name":"FSxPolicy"},"source":{"path":"SVM:vol1"}} Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships : uuid=4ae00607-8591-11ed-b3ae-09cbea4eda09 isv_name="AWS FSx" Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09/snapshots?return_records=true : {"name":"backup-0c5bad7834f251bdb"} Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers : isv_name="AWS FSx" Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers?return_records=true : {"source_snapshot":"backup-0c5bad7834f251bdb"} Success - 7 entries were displayed. # スナップショットの確認 ::> snapshot show -volume vol1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM vol1 backup-0c5bad7834f251bdb 160KB 0% 0% # スナップショットの詳細 ::> snapshot show -volume vol1 -instance Vserver: SVM Volume: vol1 Snapshot: backup-0c5bad7834f251bdb Creation Time: Tue Dec 27 02:50:59 2022 Snapshot Busy: false List of Owners: - Snapshot Size: 160KB Percentage of Total Blocks: 0% Percentage of Used Blocks: 0% Comment: - 7-Mode Snapshot: false Label for SnapMirror Operations: - Snapshot State: - Constituent Snapshot: false Expiry Time: - SnapLock Expiry Time: -
ONTAP REST APIでamazon-fsx-ontap-backup-us-east-1-1c8d1d45-678b6ae0:/objstore/0c000000-017b-975a-0000-0000003ae7a2
というS3バケットのオブジェクトとSnapMirror Cloud relationshipを作成しているようです。そしてSnapMirrorによって取得された"backup-0c5bad7834f251bdb
というスナップショットをレプリケーションしています。
SnapMirrorでバックアップ間の差分を管理しているのですね。
SnapMirror Cloudの説明は以下NetApp公式ドキュメントをご覧ください。
このまま5分ほど待つと、バックアップが完了しました。
スナップショットの名前とバックアップIDが一致していますね。
その時の監査ログは以下の通りです。
::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 02:50:50 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- ------------- ---------------------- ----------------- --------------------------------------------------------------------------------------------------------------------------- ------- ------- "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/?return_records=true : {"destination":{"path":"amazon-fsx-ontap-backup-us-east-1-1c8d1d45-678b6ae0:/objstore/0c000000-017b-975a-0000-0000003ae7a2","uuid":"0c000000-017b-975a-0000-0000003ae7a2"},"policy":{"name":"FSxPolicy"},"source":{"path":"SVM:vol1"}} Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships : uuid=4ae00607-8591-11ed-b3ae-09cbea4eda09 isv_name="AWS FSx" Success - "Tue Dec 27 02:50:59 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09/snapshots?return_records=true : {"name":"backup-0c5bad7834f251bdb"} Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers : isv_name="AWS FSx" Success - "Tue Dec 27 02:51:00 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers?return_records=true : {"source_snapshot":"backup-0c5bad7834f251bdb"} Success - "Tue Dec 27 02:55:18 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane GET /api/private/cli/storage/raid-options/?name=raid.resync.num_concurrent_ios_per_rg&fields=value Success - "Tue Dec 27 02:55:18 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane PATCH /api/private/cli/storage/raid-options/?name=raid.resync.num_concurrent_ios_per_rg : {"value":"16"} Success - 9 entries were displayed.
RAIDの同時再同期I/Oの数を指定するパラメーターが変更されていました。バックアップに直接的に関係あるかは不明です。
なお、SnapMirrorの履歴をONTAP CLIから確認してみましたが、確認できませんでした。権限レベルをadvanced
やdiagnostic
にしても確認できませんでした。
# SnapMirror relationshipの確認 ::> snapmirror show This table is currently empty. # SnapMirrorの履歴確認 ::> snapmirror show-history There is no SnapMirror history. # SnapMirrorのデスティネーションの確認 ::> snapmirror list-destinations This table is currently empty. # クラスターのピアリングの確認 ::> cluster peer show This table is currently empty. # SVMのピアリングの確認 ::> vserver peer show-all There are no Vserver peer relationships. # オブジェクトストアの確認 ::> vserver object-store-server show This table is currently empty. # オブジェクトストアの設定確認 FsxId07987ca18f2f0e911::> snapmirror object-store config show Error: "object-store" is not a recognized command
なお、NFSクライアントからボリュームのスナップショットディレクトリにアクセスすると、スナップショット取得時に存在していたファイルを確認できました。
# スナップショットディレクトリにアクセス $ ls -l /mnt/fsxn/.snapshot/ total 4 drwxr-xr-x 2 root root 4096 Dec 27 02:41 backup-0c5bad7834f251bdb $ ls -l /mnt/fsxn/.snapshot/backup-0c5bad7834f251bdb/ total 1052712 -rw-r--r-- 1 root root 1073741824 Dec 27 02:41 random_block_file
2回目のバックアップ
テスト用ファイルの作成
2回目以降のバックアップを取得する場合の挙動も確認します。
差分がないと面白くないので、テスト用ファイルを追加します。
# テスト用ファイルの作成 $ sudo dd if=/dev/urandom of=/mnt/fsxn/random_block_file_2 bs=1M count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 13.8114 s, 155 MB/s # テスト用ファイルが作成されたことを確認 $ ls -l /mnt/fsxn/ total 3158132 -rw-r--r-- 1 root root 1073741824 Dec 27 02:41 random_block_file -rw-r--r-- 1 root root 2147483648 Dec 27 04:22 random_block_file_2 # 現在のボリュームの使用量の確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com:/vol1 nfs4 9.5G 3.1G 6.5G 32% /mnt/fsxn svm-084bd75da1359a531.fs-07987ca18f2f0e911.fsx.us-east-1.amazonaws.com:/vol1/.snapshot/backup-0c5bad7834f251bdb nfs4 512M 192K 512M 1% /mnt/fsxn/.snapshot/
ボリュームのバックアップ
それではボリュームのバックアップを行います。バックアップの名前はvol1_backup_2
とします。
バックアップ開始後監査ログを確認します。
# 監査ログの確認 ::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 04:25:50 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- ------------- ---------------------- ----------------- ---------------------------------------------------------------------------------------------------------------------------------- ------- ------- "Tue Dec 27 04:27:13 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09/snapshots?return_records=true : {"name":"backup-0d7ddf2d71ae93835"} Success - "Tue Dec 27 04:27:13 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 04:27:14 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers : isv_name="AWS FSx" Success - "Tue Dec 27 04:27:14 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers?return_records=true : {"source_snapshot":"backup-0d7ddf2d71ae93835"} Success - 4 entries were displayed. # スナップショットの確認 ::> snapshot show -volume vol1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM vol1 backup-0c5bad7834f251bdb 200KB 0% 0% backup-0d7ddf2d71ae93835 168KB 0% 0% 2 entries were displayed.
スナップショットを作成し、初回バックアップ時に作成したSnapMirror Cloud relationshipを使ってレプリケーションしていました。
この後しばらくするとバックアップのステータスが利用可能
になりました。利用可能
にステータスが変わった後、再度監査ログを確認しましたが新規イベントはありませんでした。
ちなみにバックアップによって取得されたスナップショット間の差分を比較すると約2GiBでした。またバイトをブロック数で割ると4,096 Byteでした。ONTAPのデータブロックが4KiBであることが読み取れます。
::> snapshot show-delta -vserver SVM -volume vol1 -snapshot1 backup-0c5bad7834f251bdb -snapshot2 backup-0d7ddf2d71ae93835 A total of 2156961792 bytes (526602 blocks) are different. Elapsed time between the Snapshot copies: 1h 36m 14s.
また、ボリュームのバックアップ中に、さらにバックアップをしようとするとOnly one in-progress backup per volume is allowed at a given time. Try again once the backup is complete.
と怒られます。
バックアップからボリュームをリストア
次にバックアップからボリュームをリストアする際の処理を確認します。
リストアはマネジメントコンソールから行います。リストアに使用するバックアップはvol1_backup_2
です。リストアするボリュームの名前はvol1_restore
で、ジャンクションパスは/vol1_restore
とします。
リストア開始後監査ログを確認します。
::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 04:43:00 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- -------------- ---------------------- ----------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------- ------- "Tue Dec 27 04:43:47 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/?return_records=true : {"comment":"FSx.tmp.fsvol-07f621c0a8f27947b.50e4eee7-21da-4a06-a284-c148e1b80423","language":"c.utf_8","name":"vol1_restore","size":10737418240,"tiering":{"policy":"NONE"},"type":"dp","aggregates":[{"name":"aggr1","uuid":"711654b0-858b-11ed-b3ae-09cbea4eda09"}],"svm":{"name":"SVM","uuid":"77ddac30-858c-11ed-b3ae-09cbea4eda09"}} Success -
ボリュームタイプがDP
のボリュームを作成していますね。これはリストア時もSnapMirrorを使う予感がします。
その後数分待つとリストアしたボリュームのステータスが作成済み
になりました。その際の監査ログは以下の通りです。
::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 04:43:00 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- -------------- ---------------------- ----------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------- ------- "Tue Dec 27 04:43:47 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/?return_records=true : {"comment":"FSx.tmp.fsvol-07f621c0a8f27947b.50e4eee7-21da-4a06-a284-c148e1b80423","language":"c.utf_8","name":"vol1_restore","size":10737418240,"tiering":{"policy":"NONE"},"type":"dp","aggregates":[{"name":"aggr1","uuid":"711654b0-858b-11ed-b3ae-09cbea4eda09"}],"svm":{"name":"SVM","uuid":"77ddac30-858c-11ed-b3ae-09cbea4eda09"}} Success - "Tue Dec 27 04:44:18 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane PATCH /api/storage/volumes/0d0abbc0-85a1-11ed-b3ae-09cbea4eda09 : {"comment":""} Success - "Tue Dec 27 04:44:18 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 04:44:18 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/?return_records=true : {"destination":{"path":"SVM:vol1_restore"},"restore":true,"source":{"path":"amazon-fsx-ontap-backup-us-east-1-1c8d1d45-678b6ae0:/objstore/0c000000-017b-975a-0000-0000003ae7a2","uuid":"0c000000-017b-975a-0000-0000003ae7a2"}} Success - "Tue Dec 27 04:44:18 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships : uuid=1fc2c4b2-85a1-11ed-b3ae-09cbea4eda09 isv_name="AWS FSx" Success - "Tue Dec 27 04:44:19 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Tue Dec 27 04:44:19 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/1fc2c4b2-85a1-11ed-b3ae-09cbea4eda09/transfers : isv_name="AWS FSx" Success - "Tue Dec 27 04:44:19 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/1fc2c4b2-85a1-11ed-b3ae-09cbea4eda09/transfers?return_records=true : {"source_snapshot":"backup-0d7ddf2d71ae93835"} Success - "Tue Dec 27 04:45:32 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane PATCH /api/storage/volumes/0d0abbc0-85a1-11ed-b3ae-09cbea4eda09 : {"tiering":{"policy":"NONE"},"nas":{"path":"/vol1_restore"},"snapshot_policy":{"name":"none"}} Success - 9 entries were displayed.
ディスティネーションがリストア先ボリュームのSnapMirror Cloud relationshipを作成して、SnapMirror Cloudでリストアしています。リストア後にジャンクションパスへのマウントや階層化ポリシー、スナップショットポリシーを設定いますね。
リストアされたボリュームを確認します。
# ボリュームの確認 ::> volume show Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- SVM SVM_root aggr1 online RW 1GB 972.4MB 0% SVM vol1 aggr1 online RW 10GB 6.49GB 31% SVM vol1_restore aggr1 online RW 10GB 6.94GB 30% 3 entries were displayed. # スナップショットの確認 ::> snapshot show ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM SVM_root hourly.2022-12-27_0305 136KB 0% 32% hourly.2022-12-27_0405 168KB 0% 37% vol1 backup-0c5bad7834f251bdb 200KB 0% 0% backup-0d7ddf2d71ae93835 168KB 0% 0% vol1_restore backup-0d7ddf2d71ae93835 30.30MB 0% 1% 5 entries were displayed. # SnapMirror relationshipの確認 ::> snapmirror show This table is currently empty.
リストアしたボリュームvol1_restore
にはリストアに使用したスナップショットが保存されています。こちらのスナップショットの名前をよく見ると、リストアに使ったバックアップ時に取得されたスナップショットと同一のものであることが分かります。
バックアップの削除
バックアップの削除をしたときの挙動を確認します。
バックアップの削除もマネジメントコンソールから行います。
削除するバックアップはvol1_backup1
です。バックアップを選択してアクション
-バックアップを削除
をクリックします。
削除されるバックアップを確認してバックアップを削除
をクリックします。
その際の監査ログと、スナップショットの状態は以下の通りです。
# 監査ログの確認 ::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 27 04:50:00 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- -------------- ---------------------- ----------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------- ------- "Tue Dec 27 04:51:20 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane DELETE /api/snapmirror/object-stores/520cf59b-858c-11ed-b3ae-09cbea4eda09/endpoints/0c000000-017b-975a-0000-0000003ae7a2/snapshots/4b48f543-8591-11ed-b3ae-09cbea4eda09 Success - "Tue Dec 27 04:51:51 2022" FsxId07987ca18f2f0e911-01 http 52.87.48.44 FsxId07987ca18f2f0e911 fsx-control-plane DELETE /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09/snapshots/4b48f543-8591-11ed-b3ae-09cbea4eda09 Success - 2 entries were displayed. # スナップショットの確認 ::> snapshot show -volume vol1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM vol1 backup-0d7ddf2d71ae93835 172KB 0% 0%
SnapMirror Cloudのデスティネーションのスナップショットとボリューム上のスナップショットが削除されることを確認できました。
ちなみにvol1_backup1
がある状態でvol1_backup2
を削除しようとするとAmazon FSx does not support deleting the most recent backup of an ONTAP volume unless all other backups of the volume have been deleted
とエラーになります。
どうやらバックアップが複数ある場合、最新のバックアップは削除できないようです。FSx for ONTAPの監査ログにはバックアップを拒否したというイベントはなかったので、AWS側で拒否していそうです。
バックアップによって取得されたスナップショットの削除
バックアップによって取得されたスナップショットを削除できるか確認します。
vol1
のスナップショットを削除しようとしてみます。
# スナップショットの確認 ::> snapshot show -volume vol1 ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM vol1 backup-0d7ddf2d71ae93835 172KB 0% 0% # スナップショットの削除 ::> snapshot delete -vserver SVM -volume vol1 -snapshot backup-0d7ddf2d71ae93835 Error: command failed: This Snapshot copy is currently used as a reference Snapshot copy by one or more SnapMirror relationships. Deleting the Snapshot copy can cause future SnapMirror operations to fail.
SnapMirrorによって使用されているため、削除できないとエラーになりました。
リストアしたvol1_restore
のスナップショットは削除できるか確認します。
# スナップショットの確認 ::> snapshot show -volume vol1_restore ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- ------------------------------------- -------- ------ ----- SVM vol1_restore backup-0d7ddf2d71ae93835 30.30MB 0% 1% # スナップショットの削除 ::> snapshot delete -vserver SVM -volume vol1_restore -snapshot backup-0d7ddf2d71ae93835 Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure you want to delete Snapshot copy "backup-0d7ddf2d71ae93835" for volume "vol1_restore" in Vserver "SVM" ? {y|n}: y # スナップショットが削除されたことを確認 ::> snapshot show -volume vol1_restore There are no entries matching your query.
存在しているスナップショットはリストア時に使用したスナップショットであるため削除できました。
ボリュームの削除
最後にボリュームを削除した際の挙動を確認します。
マネジメントコンソールからvol1
を削除します。ボリュームを選択してアクション
-ボリュームを削除
をクリックします。
削除の確認のテキストボックスにdelete
と入力してボリュームの削除
をクリックします。
5分ほど待つとボリュームが削除されました。
その際の監査ログは以下の通りです。
# 監査ログの確認 ::> security audit log show -fields timestamp, node, application, location, vserver, username, input, state, message -state Error|Success -timestamp >"Tue Dec 28 00:50:00 2022" timestamp node application location vserver username input state message -------------------------- ------------------------- ----------- ------------- ---------------------- ----------------- ---------------------------------------------------------------------------------------------------------------------------------- ------- ------- "Wed Dec 28 00:51:17 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09/snapshots?return_records=true : {"name":"backup-01aaa4e37f074ccc8"} Success - "Wed Dec 28 00:51:17 2022" FsxId07987ca18f2f0e911-01 http 52.87.48.44 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success - "Wed Dec 28 00:51:17 2022" FsxId07987ca18f2f0e911-01 http 52.87.48.44 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers : isv_name="AWS FSx" Success - "Wed Dec 28 00:51:17 2022" FsxId07987ca18f2f0e911-01 http 52.87.48.44 FsxId07987ca18f2f0e911 fsx-control-plane POST /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09/transfers?return_records=true : {"source_snapshot":"backup-01aaa4e37f074ccc8"} Success - "Wed Dec 28 00:55:52 2022" FsxId07987ca18f2f0e911-01 http 52.204.237.29 FsxId07987ca18f2f0e911 fsx-control-plane DELETE /api/snapmirror/relationships/4ae00607-8591-11ed-b3ae-09cbea4eda09 Success - "Wed Dec 28 00:56:23 2022" FsxId07987ca18f2f0e911-01 http 35.169.159.241 FsxId07987ca18f2f0e911 fsx-control-plane DELETE /api/storage/volumes/c1a79440-858c-11ed-b3ae-09cbea4eda09 Success - 6 entries were displayed. # vol1 が削除されたことを確認 ::> volume showVserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- SVM SVM_root aggr1 online RW 1GB 971.0MB 0% SVM vol1_restore aggr1 online RW 10GB 6.97GB 30% 2 entries were displayed.
ボリュームを削除する前にSnapMirrorでスナップショットをレプリケーションしていますね。その後SnapMirror relationshipを削除した上でボリュームを削除していることが分かります。
FSx for ONTAPのボリュームのバックアップの裏側ではSnapMirror Cloudが動いている
Amazon FSx for NetApp ONTAPのボリュームのバックアップ / リストアの裏側を確認してみました。
「FSx for ONTAPのボリュームのバックアップの裏側ではSnapMirror Cloudが動いている」というドキュメントにも書いていない発見ができてテンションが上がりました。
バックアップがある限りボリューム上でスナップショットを保持するため、バックアップの保持世代数やバックアップ間の差分が多いとスナップショットのサイズも大きくなりそうです。特に「ボリュームの空き容量を何%確保しておいた方が良い」といった目安はありませんが、ボリュームの使用率が98%を超えるとバックアップの取得ができません。
データをバックアップするには、ボリュームとファイルシステムのプライマリ SSD ストレージ層の両方に、バックアップスナップショットを作成するのに十分なストレージ容量が必要です。ボリュームスナップショットのために追加で消費される容量によってボリュームの使用率が 98% を超える場合は、バックアップスナップショットを作成することはできません。ボリュームのプライマリ SSD ストレージ層の使用率が 80% を超えないようにするのがベストプラクティスです。
そういった意味でもボリュームの使用率はCloudWatchで監視しておきたいですね。
最初からどの程度スナップショット間で差分が発生するのか予想するのは難しいと思います。そのため、CloudWatchでボリュームの使用率が80%など閾値を超えた際にボリュームのサイズを拡張するなど運用中に随時見直していくのが良いと考えます。FSx for ONTAPのボリュームはシンプロビジョニングで拡張/縮小を素早く行えるので、そういった対応でも良いと思います。個人的には実データの120%ぐらいでサイジングして様子を見ようと思います。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!